【レポート】「＜みずほ＞がクラウド活用のために取り組んだこと ～デザインパターンとLanding Zone～」AWS Summit Tokyo 2019 #AWSSummit

こんにちは、臼田です。

こちらは2019年06月12〜14日に行われたAWS Summit Tokyo 2019のセッションレポートです。

本ブログでは『＜みずほ＞がクラウド活用のために取り組んだこと ～デザインパターンとLanding Zone～』に関する内容をレポートしたいと思います。

• AWS Summit Tokyo 2019 | 2019 年 6 月 12 (水) 〜14 (金) 幕張メッセで開催

セッション概要

当セッションの登壇者及び概要は以下の通りです。

株式会社みずほ銀行 IT・システム統括第一部 調査役

佐粧 茂雄

株式会社みずほフィナンシャルグループ リテール・事業法人業務部 調査役

山泉 亘

みずほフィナンシャルグループは、市場で加速するデジタル化の流れを注意深くウォッチしており、「テクノロジーなしでビジネスは発展も改善もできない」との共通認識のもと、新たな価値をお客様へ迅速に提供するためにシステム高度化・改善に取り組んでいる。デジタル化テクノロジーの1つの選択肢として、パブリッククラウド（AWS）へどのように向き合い、どんな着地点を見出したのか。本セッションではその全体感をご説明します。

レポート

• このセッションでは他のみずほのセッションから繋がっている、実際の実装などの細かい話をしていく
• みずほは試されている
  • 銀行業として変えていかないと行けない事がある
  • キャッシュフルの売店の現場など
• 伝えたいこと
  • みずほがクラウドを使うために取り組んだこと
  • デザインパターンとLanding Zone
  • デザインパターンはどう使えばいいのか
  • Landing Zoneは実現のために全体最適化をするための共通フレームワーク
• クラウド活用の背景と狙い
  • なぜクラウドを使うのか
    • 金融機関だからといって特別な期待をしているわけではない
    • スピード・柔軟性・コスト低減
    • ただし安全に
      • 個々を厳しく見るのが金融業
  • クラウドを使って何を為そうとしているのか
    • 金融機関、金融業、お金、お客様の価値観が変化している
    • 変化の結果は誰もわからない
    • 成長し続けるために、変化し続けるために失敗できる体力と体質が必要になる
  • なぜAWSなのか
    • 使っている人が多い
      • リスク観点の点ではとても大事
    • 高品質でも欠点のないソフトウェアは存在しない
    • 困った時に助け合える環境
      • リカバリーが容易
• 活用までのアプローチ
  • 全体の流れ
    • クラウドによるメリットの全員理解
    • リスク評価とデザインパターン
    • コスト評価とLanding Zone
    • 社内合意形成
  • クラウドによるメリットの全員理解
    • 何ができるようになるのかを知る
      • IT部門だけじゃなくてユーザ部も含めて全員
    • ビジネスメリットは全員で理解する(役割分担はその後)
  • リスク評価とデザインパターン
    • オンプレミスと前提が異なる
      • リスクは増える
    • 増えるリスクは新しくない
      • 既に世の中で鍛えられている
    • リスク対策を考慮したアーキテクチャ
      • デザインパターン
    • パブリッククラウド固有のリスクと対策
      • 誤設定でデータを更改
        • チェックポイントと役割分担
      • などなど、既知の内容
  • コスト評価とLanding Zone
    • リスク対策は「打つ場所」と「打ち方」が重要
    • 全体最適化のための共通化
      • Landing Zone(共通フレームワーク)
    • 何でもかんでも共通化すればいいわけではない
      • バランスが大事
  • 社内合意形成
    • 経営層、現場担当両面から当事者意識の醸成が必要
    • ユーザ部門、IT部門、外部パートナーを繋ぐ役割の存在が重要
    • CCoEがキモ
• リスク評価とデザインパターン
  • これまでを大切に
    • 開発規定、設計標準、ガイドラインなどを大事に
    • オンプレミス前提で作られたものでも一から作り直す必要ない
    • 自社ポリシーを抽出
      • クラウドならどうするを考える
    • 規定や標準の中の背景を辿るのは難しい
      • 暗号化しなさい、ではなくなぜ暗号化しないといけないのかを探る必要がある
  • リスクの捉え方
    • どのデータを持ち込む(持ち込まない)？
      • やめたほうがいい
      • データの分離が出来ないため
      • やるとビジネス的に厳しくなる
    • どんなデータであれ守る
      • 脅威から守る
      • では脅威はどこに？
    • ビジネス分析の重要性、アクターとデータの関係性を可視化
      • 脅威は外部やユーザがインターネット越しなので一般的にある
      • しかし内部も十分脅威
        • こちらのほうが厄介
        • 内部事情を知っているから
    • これまでは「通信制御」(ネットワークゾーニング)
      • どこからど声、どんなアクセスを許可するか
      • オンプレミスでは一般的、クラウドでもIaaSまでは可能
      • ただしPaaS/SaaSでは利用が進展すると適用しにくくなる
      • サービス部分は細く手を入れられない
    • これからは「認証・認可」(AuthN/AuthZ)
      • 誰にどんな操作をどんな条件で許可/拒否するのか
      • オンプレ/IaaS活用とPaaS/SaaS活用には大きなGAP
      • アーキテクティングを刷新
        • 利用促進にはパターン化が急務
    • リスク評価からのパターン導出
      • 自社ポリシーで各サービスのリスク評価
      • ポリシーに合わせたAWSの使い方
    • 人だけでなく組織として知識定着
      • 業務課題やシステム課題に対するユースケース粒度
      • テクニックに凝りすぎない、こだわりすぎない
• コスト評価とLanding Zone
  • AWS責任共有モデルにおけるみずほの責任
    • システム共通部分とアプリ固有部分に分類
    • 共通部分は予めシステム設定を実施して環境払い出し
    • 共通フレームワーク(Landing Zone)を適用したAWS環境をみずほAWSと定義
  • みずほAWSの特徴
    • マルチアカウント方式
    • 共通アカウント
      • システム共通での機能提供
      • セキュリティなどを担保
    • テナントアカウント
      • 利用アプリ(システム)用途別にアカウントを作成
      • AWSのサービスを自由に使える
  • 権限管理(認証・認可)
    • IAMを用いてポリシーを統一化
    • 共通アカウント上にIAM作成
      • ここから各テナントにアクセス
    • グローバルIPでのアクセス制限も共通アカウントで実施
    • 認可
      • テナントアカウントに職務・役割に応じて権限の異なるロールを容易
      • IAMユーザIDとのヒモ付でアクセス範囲もコントロール
        • 何をしていいかは共通で
        • どこにアクセスしていいかはテナント側で管理
      • セキュリティ設定件店は一部の要因へ集約
        • クラウド利用開始時期のため
        • 浸透してきたら別
  • ネットワーク
    • VPC/DirectConnectを用いてインターネットと分離したセキュアな環境を整備
    • オンプレミスネットワークをAWSへ延伸
  • DNS
    • オンプレミスネットワーク端末/サーバ-みずほAWS内サーバ通信における名前解決
    • みずほAWS内サーバ間通信における名前解決
    • ピアリングして共通のRoute53を参照
  • クラウドHUB
    • オンプレミスネットワーク - みずほAWS間を接続
    • PaaS/SaaS接続時のパブリックIPルーティング影響を極小化
  • ログ収集・管理
    • 各テナントアカウントのログを収集し監査アカウントのS3へ保管
    • 保管ログは他テナントからはアクセス不可
    • 保管ログアクセス時はアクセスログを別のS3へ取得・保管
  • 監査
    • 取得ログにより各種監査計表を出力
    • IAM IDの利用状況等をチェック
    • クラウド設定チェック(検討中)
      • 当初は検知のみ
      • その後自動修正まで盛り込む
  • 整備で心がけたこと
    • できる限りAWSサービスを活用し、独自開発は最小限に抑制
      • クラウドサービスは日々改善
  • システム共通化まとめ
    • 予防的統制と発見的統制のバランスが大事
    • AWSベストプラクティスの活用をする
• 苦労したところと今後の課題
  • 自由度 vs ガバナンス
    • 現状ではクラウドを始めたばかりなのでガバナンスを強めにしている
  • AWSサービスの利用制限
    • 各サービス認定に時間・コストがかかる
  • セキュリティ設定権限の特定要因への集中
    • 事故につながる恐れのある設定はテナントから特定要因へ設定依頼
      • スピード・柔軟性に欠けコストも増加
      • スキル向上に繋がらなくなることも
        • OJT等でできるようにしていく
  • 将来は
    • 教育・スキル向上・自動化をして自由にしていきたい
  • その他の課題
    • Control TowerやSecurity Hub等新しいサービスも活用したい
• お伝えしたいこと
  • リスク評価の結果としてデザインパターンを整備
  • コスト評価の結果としてLanding Zoneを整備
  • これまでを知り、これからを知り、変革をリードするのがCCoEの仕事
  • 人が大事
    • コミュニケーションスキルはCCoEに必須
• Amazon Connectの実証実験を行っている
• クラウドの機能を使った実証実験も増えているのでまた発表したい

感想

Landing ZoneはAWSが提唱している一つの手法ですが、日本の企業でもしっかり適用されていて素晴らしいなと思いました！

ぜひ今後も新しい取り組みを話していっていただきたいです！